-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(web): prevent cookie-default behavior from mangling engine init #13331
Conversation
Fixes: #13278 The fallback default keyboard corresponding to an uninitialized cookie is `Keyboard_us:en`. This should only occur if the site actually registers its stub before initialization - and we weren't checking/filtering for this properly. The error itself only occurred if there _were_ stubs pre-registered before init - if none existed, the error does not result.
User Test ResultsTest specification and instructions Test Artifacts
|
// doAddKeyboards({id:'us',name:'English',languages:{id:'en',name:'English'}, | ||
// filename:(prefix + 'us-1.0.js')}); | ||
|
||
// Do NOT link the us-1.0 keyboard here! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the difference between the original "commonHeader.js" and this specialized version - we do not want the us
/ Keyboard_us
keyboard here, as its presence will greatly affect attempts to reproduce this PR's base issue.
@@ -820,11 +820,14 @@ export default class ContextManager extends ContextManagerBase<BrowserConfigurat | |||
} | |||
|
|||
// Find the matching stub; if it doesn't exist, default to the first available stub. | |||
let stub = this.keyboardCache.getStub(t[0], t[1]) || this.keyboardCache.defaultStub; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way this original line worked was at the core of the error we saw. If we had any default stub, that was enough to try activating the Keyboard_us
keyboard if given the signal - regardless of whether or not it was present!
Test ResultsI tested this issue with the attached Keyman"18.0.197-beta-test-13331" build(24/02/2025) on the Web(KeymanWeb Test Page - Keyboard Quick-Load) page. Here I am sharing my observation.
|
Changes in this pull request will be available for download in Keyman version 18.0.201-beta |
Fixes: #13278
The fallback default keyboard corresponding to an uninitialized cookie is
Keyboard_us:en
. This should only occur if the site actually registers its stub before initialization - and we weren't checking/filtering for this properly.The error itself only occurred if there were stubs pre-registered before init - if none existed, the error does not result.
User Testing
TEST_WEB_PAGE_INIT: Using the KeymanWeb test page titled "Test OSK loading with early add-keyboard calls (#11785)", verify that the page initializes smoothly, without errors or alerts.